home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2510 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB
  1. Path: camelot.dsccc.com!not-for-mail
  2. From: kcline@sun132.spd.dsccc.com (Kevin Cline)
  3. Newsgroups: comp.sys.sun.apps,comp.lang.c++
  4. Subject: Re: Which one is better, Object Center or SparcWork for Sun C++ development?
  5. Date: 17 Jan 1996 22:46:54 -0600
  6. Organization: DSC Communications Corporation Switch Products Division
  7. Message-ID: <4dkjbu$rur@sun132.spd.dsccc.com>
  8. References: <4djgqd$dcc@henry.netaxis.com>
  9. NNTP-Posting-Host: sun132.spd.dsccc.com
  10.  
  11. In article <4djgqd$dcc@henry.netaxis.com>,
  12. Gower Tang <gtang@netaxis.com> wrote:
  13. >
  14. >Hi,
  15. >
  16. >    My company wants to buy a C++ development suite for our Suns,
  17. >can you please forward your opinion on the above-mentioned suites?
  18. >
  19.  
  20. A year ago I worked on a medium-scale (100K? SLOC) for American
  21. Airlines that started with ObjectCenter.  As soon as Sun came out with
  22. their new (non-cfront) C++ compiler (SparcWorks version 3, C++ version
  23. 4) we abandoned ObjectCenter, primarily because of compiler speed.  We
  24. used templates very heavily.  At the time, Centerline supplied the
  25. vanilla AT&T compiler with ObjectCenter, and it's link-time template
  26. expansion was very very slow compared with the Sun compiler's
  27. compile-time expansion.  The Sparcworks compiler was also able to
  28. generate much better code than the AT&T compiler. I don't know what
  29. compiler comes with ObjectCenter now.
  30.  
  31. There were inconsistencies between the OC interpreter and the
  32. AT&T (cfront) compiler.  The user interface is not really Motif, and
  33. not really OpenLook either; I found it annoying to use and quite
  34. buggy.  It was deathly slow to load 30K lines of code into
  35. ObjectCenter.  I also got the impression that Centerline was a bit
  36. strapped for cash, because many OC bugs that should have been easy to
  37. fix hung around through multiple minor releases.  Again, I haven't
  38. used their product for a year.  
  39.  
  40. DSC also had ObjectCenter and I believe it's been abandoned here too.
  41.  
  42. To be fair, there are nits in Sparcworks too.  The 'debugger' GUI is
  43. still OpenLook style, and I find it so awful I just use dbx.  If you
  44. know emacs, then you could try using edb; it's one of those things I
  45. keep meaning to get around to.  There are some problems with dbx's C++
  46. expression evaluator too; in particular, it doesn't convert operator
  47. expressions into a call to an operator function.
  48.  
  49. On the whole, though, I am pretty happy with the Sun's compiler team;
  50. posts to this newsgroup from Mike Ball and Steve Clamage show that the
  51. team is doing a good job of following the DWP and also that they are
  52. listening for feedback from their users.  I wish they would go ahead
  53. and provide RTTI and bool though.
  54.  
  55. I think you would be better off forgetting about purchasing an IDE
  56. and just use the SparcWorks compiler and dbx with GNU Emacs.
  57.  
  58. I also recommend that you purchase Purify, Quantify, and Purecov; these
  59. products are incredibly well-engineered.  They are so good that I don't
  60. think anyone should even bother trying to do better.  They are very
  61. easy to use with a near-perfect user interface and top-notch documentation. 
  62.  
  63. Kevin Cline
  64.  
  65. -- 
  66. Kevin Cline
  67.